1. Field of the Invention
The invention relates generally to data communications with a network switch, and, more particularly, to implementing multicasting within a network switch.
2. Related Art
The rapidly increasing popularity of networks such as the Internet has spurred the demand for network services. In order to meet the demand for the increased network services, it has been found that increasing the size of frames typically increases the through-put of a network and therefore meets the increased demand.
The prior art networks typically used a 1518 byte frame size that was designed to protect against the high error rate of physical-layer Ethernet components. However, computer processing power has increased by an order of magnitude, and moreover the use of switched Ethernet over various media has significantly reduced errors. With these reduced errors, larger frame sizes may now be used with greater success.
Increasing the frame size typically reduces server overhead, increases throughput and the like, and has become an attractive option. However, typical switches have experienced a number of problems handling the larger frame size, for example, during multicast transmissions. In particular, as described in further detail below, the increased frame size results in an increased number of pointers for each frame that must be handled by multiple ports associated with the multicast transmission. The increased number of frames in conjunction with the increased transmissions with multicasting creates a bottleneck in handling pointers that decreases efficiency and speed.
FIG. 1 schematically shows a conventional network 100 in which a known network switch 102 connects devices 104A-104N and 112A-112N. Each of the devices 104A-N, 112A-N can be any network device, such as a computer, a printer, another network switch, or the like. Switch 102 transfers data between the devices 104A-N, 112A-N over channels 106A-N and 114A-N. The channels 106A-N and 112A-N can include fiber optic links, wireline links, wireless links, and the like.
In the typical known network switch 102, a queue controller 122 manages and assigns pointers to a buffer 108. The buffer 108 typically stores frame data received from any one of the devices 104A-N and 112A-N. A typical frame has its data fragmented into many discontinuous portions in the buffer 108. The queue controller 122 then typically organizes these portions with lists of pointers and forwards these lists from ingress of frames to egress of frames through ports of ingress modules 134A-N (ingress) and egress modules 136A-N (egress).
Accordingly, as frames are received in the switch 102, they are stored in the buffer 108. The location of the frames in the buffer 108 is based upon the pointers as is well known in the art. The process becomes more difficult with large frames. For example, a large frame size implementation may need 20 pointers per port, and utilizing fragmented 128 byte buffers would require 80 pointers per port. This results in increased cost and complexity for the memory and the switch. In previous designs, the typical switch had 256 total pointers, and a frame consisted of up to 3-4 pointers.
This conventional process is even more difficult and complicated with larger frames and multicasting. The queue controller 122 typically includes a multicasting module 124 for multicasting operations. Multicasting can include the transmission of a single frame from one or more ports. Thus, a pointer can be used by multiple ports. The multicasting module 124 typically controls when egressed buffer pointers may be returned to the free list 126. Some prior art implementations use a counter variable that indicates how many output queues the pointer remains waiting for transmission. When a pointer egresses a port, the multicasting module 124 decrements this counter variable. When the counter variable reaches 0, the multicasting module 124 returns all of the frame's pointers to the free list 126.
Another prior art queue controller implementation may use a memory more optimally by returning pointers to the free list 126 when all of the destination output queues have been successfully egressed a memory portion associated with a pointer. Other architectures may wait for the whole frame to egress all of the destination output queues, and thereafter return all of the frame's pointers at once. To implement the various control schemes, each pointer in a frame must maintain a variable indicating which or how many ports the pointer has been enqueued to and not yet egressed.
A further known implementation uses a bit vector, the bit vector value indicates that the pointer in a corresponding port's output queue should transmit a frame. When a pointer egresses from a particular port, the multicasting module 124 clears the corresponding bit in the vector (sets the bit=0). When the bit vector has all values equal to 0, the pointer is returned to the free list 126. In each of the above noted cases, the variables and/or vectors are stored in a memory. The memory is typically the memory in the multicast module. The variables and memory are accessed as follows.
Initially, a reserve list 128 typically builds a link list for a frame as pointers are provided to the ingress. The ingress receives a frame along one of channels 106A through 106N. When frame reception ends, ingress and the queue controller 122 and its associated reserve list 128 then forwards the frame to one or more output priority queues as indicated by a bit vector destination port vector (hereinafter “DPV”).
Thereafter, a forwarding module typically enqueues the frame to all of the various destination output priority queues. The forwarding module then typically must write the DPV field to the multicasting module 124 memory for each pointer in the frame as schematically shown in FIG. 1.
When an output queue and its associated egress module successfully transmits the frame data in the buffer 108 addressed by the pointer, the output queue dequeues the pointer to the multicasting module 124.
Thereafter the multicasting module 124 reads the DPV field from the multicasting module 124 memory entry addressed by the pointer. The multicasting module 124 then typically clears the appropriate bit to 0. Subsequently, the multicasting module 124 writes a new DPV value to the multicasting module 124 memory entry addressed by the pointer. If the new DPV value is all zeros, the multicasting module 124 returns the pointer to the free list 126.
When using jumbo frames, the switch must fragment a frame into F buffers (F being an integer number). In order to store the frame into F buffers, the switch must perform F DPV writes per frame. For an implementation with N ports in a switch, the switch requires N times F DPV writes in order to complete the multicast switching process (see FIG. 1). Moreover, in order to meet basic speed requirements, the switch must complete the N time F writes in less than a minimum frame size time. The result of this increased number of pointers due to the jumbo frame size quickly becomes a bottleneck in the switching process that involves multicasting due to the need to write the DPV value to memory N times F times.
More specifically this prior art approach is highly wasteful because there is only one DPV value per frame, and the forwarding module writes this same value F times for each pointer in the frame.
Accordingly, there is a need for a network switch that provides for more efficient multicasting capability than that currently realized when using larger size frames and/or multicasting.